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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 17 September 2008 appealing from the 
Office action mailed 14 July 2008. 
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(1) Real Party of Interest 

A statement identifying by name the real party of interest is contained in the brief. 

(2) Related Appeals and Interferences 

An Appeal has been filed in related U.S. Patent Application No. 10/675,503. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

2002/0032616 Suzuki et al. 3-2002 

2002/0052842 Schuba et al. 5-2002 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
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Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 1-7, 9-13, and 15-18 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Suzuki et al. (US PG Pub. No. 2002/0032616), [hereinafter Suzuki] in 
view of Schuba et al. (US PG Pub. No. 2002/0052842), [hereinafter Schuba]. 

Referring to Claim 1 : Suzuki shows a mobile server wallet provider (MSWP) 
[portal] comprising: a configuration for communicative coupling both to a plurality of 
MSWP's and also a content proxy [wallet server] (Suzuki: Figures 3-4, 6-7; Page 2, 
Paragraph 0030//The figures depict a system that facilitates the transactions between 
multiple MSWP's where a content proxy [wallet server] would allow retrieval of various 
amounts of information regarding the MSWP//); a composite profile generator 
configured to combine a plurality of MSWP profiles into a single, composite profile for 
routing payment messages in said proxy [wallet server] to the MSWP [portal] (Suzuki: 
Page 2, Paragraph 0021, 0030// Suzuki refers to a system which combines multiple 
MSWP's and allows for financial transactions to take place//); and, selection logic 
configured to process a user selection of one of said MSWP's to process a payment 
transaction received through said proxy [wallet server] (Suzuki: Figures 3, 4, 7; Page 2, 
Paragraph 0020-0023//Upon verification of receipt, a payment transaction process 
occurs with the system//). 
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Suzuki, however, does not expressly discuss a wallet 'portal'. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are number of servers within the system 
of Schuba (//Unarguably, the server which corresponds more effectively to the operation 
of a proxy, teaches the proxy server of the instant application//). Furthermore, it is old 
and well known in the art that upon use of a mobile wallet, a composite profile is created 
for a user/subscriber in order to allow for quicker usability during each 
successive/subsequent use, thereby reducing the continuous data/bandwidth input into 
the system caused via each transaction. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
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payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 2 : Suzuki discusses a [portal//communication device//], 
wherein said content proxy [wallet server] is a wireless service proxy [wallet server] 
(Suzuki: Page 1, Paragraphs 0008-0011; Page 4, Paragraph 0049//Suzuki discloses a 
system which consists of a wireless service proxy via the Internet - Various 
communication devices are mentioned which are capable of maintaining wireless 
service proxy transmission//). 

Referring to Claim 3 : Suzuki discloses [a portal], wherein the WSP comprises [a 
filter plug-in] configured to route said payment messages [to the portal] when said 
payment messages match rules specified within said composite profile (Suzuki: Page 2, 
Paragraphs 0028-0029; Page 3, Paragraphs 0033-0038//After authentication takes 
place within the network, payment messages are routed back and forth via the 
system//). 

Suzuki, however, does not expressly show a portal as discussed supra or a filter 
plug-in. 

The Examiner takes Official Notice to the fact that it is quite common and well 
known to one of ordinary skill in the art that a filter be involved in an initiation of an 
electronic payment transaction, a communication terminal of a customer, or a 
transaction server. A filter serves as a primary part of the communication system; the 
communication system allows a communication between the server of the merchant, 
the communication terminal and the transaction server. The filter has, among others, 
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the task of forwarding certain messages concerning the electronic payment transaction 
to assigned receivers. Filters can be a part of a communication system, such as a GSM, 
GPRS, PPDC, WCDMA, UMTS, and Bluetooth type networks by way of example. In 
addition, a filter allows for, among other things, the ability for certain messages to be 
redirected to the transaction server for the communication terminal. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are a numerous amount of servers within 
the system of Schuba (//Unarguably, the server which corresponds more effectively to 
the operation of a proxy, teaches the proxy server of the instant application//). 
Furthermore, it is old and well known in the art that upon use of a mobile wallet, a 
composite profile is created for a user/subscriber in order to allow for quicker usability 
during each successive/subsequent use, thereby reducing the continuous 
data/bandwidth input into the system caused via each transaction. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
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payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 4 : Suzuki teaches a payment transaction system comprising: 
a plurality of mobile server wallet providers (MSWP's) coupled to respective on- 
line financial institutions (Suzuki: Figures 3-4, 6-7; Page 2, Paragraphs 0024, 0030; 
Page 4, Paragraphs 0052-0053//Suzuki depicts a system which combines multiple 
MSWP's, and allows for financial transactions to take place which have a relation with 
multiple financial institutions of varying types//); at least one content proxy [wallet 
server] configured for coupling both to on-line merchants and to end user customers of 
said on-line merchants (Suzuki: Figure 1(#40); Page 3, Paragraph 0048; Page 4, 
Paragraphs 0053//The system as disclosed can be utilized by both on-line merchants 
and end-users//); and, at least one MSWP [portal] disposed between the MSWP's and 
at least one content proxy [wallet server] (Suzuki: Page 2, Paragraphs 0021, 0030; 
Page 3, Paragraph 0031). 

Suzuki, however, does not expressly discuss a wallet 'portal'. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
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a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are a numerous amount of servers within 
the system of Schuba (//Unarguably, the server which corresponds more effectively to 
the operation of a proxy, teaches the proxy server of the instant application//). 
Furthermore, it is old and well known in the art that upon use of a mobile wallet, a 
composite profile is created for a user/subscriber in order to allow for quicker usability 
during each successive/subsequent use, thereby reducing the continuous 
data/bandwidth input into the system caused via each transaction. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 5 : Claim 5 parallels the limitations of Claim 2. As such, Claim 
5 is rejected under the same basis, as is Claim 2 as mentioned supra. 

Referring to Claim 6 : Suzuki discusses a system, wherein said content proxy 
[wallet server] further comprises [a filter plug-in] configured to route payment messages 
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to said MSWP [portal] when said payment messages match rules specified within a 
profile provided to said [filter plug-in] by said MSWP [portal] (Suzuki: Page 2, 
Paragraphs 0028-0029; Page 3, Paragraphs 0033-0038//After authentication takes 
place within the network, payment receipt messages are routed back and forth 
throughout the system//). 

Suzuki, however, does not expressly show a portal as discussed supra or a filter 
plug-in. 

The Examiner takes Official Notice to the fact that it is quite common and well 
known to one of ordinary skill in the art that a filter be involved in an initiation of an 
electronic payment transaction, a communication terminal of a customer, or a 
transaction server. A filter serves as a primary part of the communication system; the 
communication system allows a communication between the server of the merchant, 
the communication terminal and the transaction server. The filter has, among others, 
the task of forwarding certain messages concerning the electronic payment transaction 
to assigned receivers. Filters can be a part of a communication system, such as a GSM, 
GPRS, PPDC, WCDMA, UMTS, and Bluetooth type networks by way of example. In 
addition, a filter allows for, among other things, the ability for certain messages to be 
redirected to the transaction server for the communication terminal. 

Schuba, in a similar environment, teaches a wallet portal where a mobile server 
wallet transaction takes place. The Examiner notes that Schuba discusses the usage of 
a wallet server, which comprises an entity that operates between a merchant and a 
customer. This 'single entity' is located within the transaction between the merchant and 
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a consumer and is used by both. The consumer communicates with the wallet, and the 
wallet, in turn, communicates with the merchant through the merchant's website. In 
effect, it would be obvious to conclude that this entity is thus likened to serve as a 
'portal' in order to achieve successful system interoperability as disclosed; henceforth, a 
portal is taught in Schuba. Additionally, there are number of servers within the system 
of Schuba (//Unarguably, the server which corresponds more effectively to the operation 
of a proxy, teaches the proxy server of the instant application//). Furthermore, it is old 
and well known in the art that upon use of a mobile wallet, a composite profile is created 
for a user/subscriber in order to allow for quicker usability during each 
successive/subsequent use, thereby reducing the continuous data/bandwidth input into 
the system caused via each transaction. 

At the time of the invention it would have been obvious to one of ordinary skill in 
the art to modify the teachings of Suzuki for a relay server, relaying method and 
payment system with the features of Schuba for an electronic wallet server payment 
transaction for the purpose of creating a greater more robust and efficient system that 
also allows for ease of user interaction and protection/safety for user when making 
payments and/or transactions while using the system (Schuba: Page 1, Paragraph 
0002-Page 2, Paragraph 0018). 

Referring to Claim 7 : Suzuki discloses a method for processing a payment 
transaction in a mobile commerce system (Suzuki: Page 2, Paragraph 0016; Page 3, 
Paragraphs 0031-0032//Suzuki discloses a e-commerce payment transaction system 
and method//), the method comprising the steps of: processing a payment message in a 
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[portal] to identify one of a selection of mobile server wallet providers to handle an 
associated payment transaction (Suzuki: Page 2, Paragraph 0016; Page 3, Paragraphs 
0031-0032//A payment transaction is dedicated to a given mobile server wallet//); 
routing said payment message to said payment message to an identified one of said 
MSWP's (Suzuki: Page 2, Paragraphs 0016, 0023; Page 4, Paragraphs 0052-0053//A 
unique identifier is traced with the payment transactional information//); combining 
individual MSWP profiles for each of said MSWP's into a composite profile (Suzuki: 
Figures 3-4, 6-7; Page 2, Paragraph 0030//Suzuki teaches a system and method which 
facilitates transactions between multiple MSWP's where a content proxy [wallet server] 
allows retrieval of financial information regarding the MSWP, thereby causing storage to 
a composite profile//); and, providing said composite profile to a content proxy [wallet 
server] for use in trapping payment messages passing through said content proxy 
[wallet server] between an on-line merchant and a customer in the mobile commerce 
system (Suzuki: Page 1, Paragraphs 0008-0011; Page 4, Paragraph 0049). 

Referring to Claim 9 : Suzuki shows a method of processing comprising the steps 
of: identifying a customer associated with said payment message (Suzuki: Page 2, 
Paragraphs 0016, 0021, 0028//Suzuki teaches a system where a user [customer] is 
identified//); parsing a profile associated with said customer to determine a selection of 
preferred MSWP's (Suzuki: Figure 3-Also See Page 4, Paragraphs 0059-0060//Suzuki 
displays a system which allows a selection of various MSWP's//); rendering a user 
interface presenting said selection of preferred MSWP's to said customer (Suzuki: 
Figure 3-Also See Page 4, Paragraphs 0059-0060); and, selecting a particular one of 
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said preferred MSWP's to handle said associated payment transaction based upon data 
provided by said customer in said user interface (Suzuki: Page 5, Paragraphs 0061- 
0064//A financial payment transaction occurs at this juncture in the system, upon final 
selection of a MSWP//). 

Referring to Claim 10 : Suzuki discusses a method comprising the step of relaying 
payment transaction data produced by said selected one of said preferred MSWP's to a 
customer (Suzuki: Page 3, Paragraph 0021; Page 8, Paragraphs 105, 106, 
1 10//Communication between a MSWP and a customer are described//). 

Referring to Claim 1 1 : Suzuki discloses a method comprising the step of relaying 
payment transaction data produced by said selected one of said preferred MSWP's to a 
merchant associated with said payment transaction (Suzuki: Page 3, Paragraph 0021; 
Page 8, Paragraphs 105, 106, 110//Communication between a MSWP and a merchant 
are described//). 

Referring to Claim 12 : Suzuki teaches a method wherein said relaying step 
comprises the step of relaying a payment guarantee to said merchant by said selected 
one of said preferred MSWP's (Suzuki: Page 2, Paragraphs 001 6-001 7//While no 
'formal' guarantee is expressly mentioned by Suzuki, the transaction will not terminate 
until payment has been received, hence, a payment guarantee is in effect//). 

Referring to Claims 13-18 : Claims 13-18 are directed towards a machine 
readable storage for Claims 7-12. As such Claims 13-18 are rejected under the same 
basis as are Claims 7-12 as mentioned supra. 
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(10) Response to Argument 

Appellants argue: 

1. As is evident from Appellants' previously-presented comments during 
prosecution of the present Application and from Appellants' comments below, there are 
questions as to how the limitations in the claims correspond to features in the applied 
prior art. In this regard, reference is made to M.P.E.P. § 1207.02, entitled "Contents of 
Examiner's Answer." Specifically, the following is stated: 

(A) CONTENT REQUIREMENTS FOR EXAMINER'S ANSWER. The examiner's 
answer is required to include, under appropriate headings, in the order indicated, the 
following items: (9)(e) For each rejection under 35 U.S.C. 102 or 103 where there are 
questions as to how limitations in the claims correspond to features in the prior art even 
after the examiner complies with the requirements of paragraphs (c) and (d) of this 
section, the examiner must compare at least one of the rejected claims feature by 
feature with the prior art relied on in the rejection. The comparison must align the 
language of the claim side-by-side with a reference to the specific page, line number, 
drawing reference number, and quotation from the prior art, as appropriate, (emphasis 
added) 

Therefore, if the Examiner is to maintain the present rejections and intends to file 
an Examiner's Answer, the Examiner is required to include the aforementioned section 
in the Examiner's Answer. 

As noted in the First Appeal Brief dated April 8, 2008, the Examiner failed to 
specifically identify the teachings being relied upon in the rejection as required under 
with 37 C.F.R. §1.1 04(c). Previously, the Examiner rejected the claims under 35 U.S.C. 
§ 102 for anticipation based upon Suzuki, whereas in the current rejection the Examiner 
is relying upon Suzuki to teach most of the claim limitations and Schuba to teach "a 
wallet portal" (see page 3 of the Third Office Action). However, the Examiner's analysis 
in the Third Office Action still fails to clearly explain the pertinence of Suzuki. 

1. The Examiner responds in detail below: 
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The Examiner wishes to clarify the matter as to the pertinence of Suzuki to show 
certain limitations. While the third office action does, on Pages 3-4, show a reliance on 
Suzuki in order to show a portion of the elements of the claim language within Claim 1 , 
the Examiner relied upon the combination of both Suzuki and Schuba to discuss the 
limitations found within Claim 1. On Pages 3-4 of the third office action it should be 
noted that the contents of which the examiner did not specifically rely upon within 
Suzuki were placed within brackets: "[portal]". The "[wallet server]" relates to the 
content proxy of Claim 1 - it is quite clear that the Suzuki reference discloses at least a 
wallet server. The Examiner then relied upon the Schuba teachings to discuss the 
portal, which is not expressly shown within the Suzuki reference shown on Page 3 of 
the third office action. 

2. Claim 1 

On pages 8 and 9 of the First Response dated November 15, 2007 (hereinafter 
the First Response), Appellant presented the following arguments. At the outset, 
Appellant notes that the Examiner's written analysis with regard to claim 1 has been 
little assistance to Appellant in understanding the basis for the Examiner's rejection. For 
example, the Examiner refers to "[server]" as identically disclosing the claimed content 
proxy. However, Figs. 3 and 4 of Suzuki describe four different servers. Appellant is not 
in a position to guess as to what "server" in Suzuki the Examiner is referring to 
identically disclose the claimed content proxy. 

Appellant also notes that the Examiner's analysis relies on generalizations and 
ignores the specific language of the claims. Also, the Examiner's cited passages of 
Figures 3-4 and 6-7 as well as paragraphs [0020]-[0023] and [0030] of Suzuki describe 
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what Appellant has already admitted is prior art (i.e., see Fig. 1 of Appellant's 
specification). 

2. The Examiner is unclear as to the Appellants comment "... the 
Examiner's written analysis with regard to claim 1 has been little assistance to 
Appellant in understanding the basis for the Examiner's rejection." and while not 
finding this argument persuasive, discusses the argument in detail below: 

As best understood, the Examiner has included a chart below which better 
discloses the portions of the references which have been relied upon within the rejection 
on appeal in efforts to further "provide a claim construction for the claim language 



at issue". 



CLAIM & LIMITATION 


REFERENCE # 1 


REFERENCE #2 




Suzuki etal. (2002/0032616) 


Schuba et al. (2002/0052842) 




teaches this limitation at: 


teaches this limitation at: 


1 






a mobile server wallet 
provider (MSWP) 
comprising: a configuration 

for communicative 
coupling both to a plurality 
of MSWP's and also a 
content proxy; 


Abstract; Figs. 3-4,6-7; Pg 2, Para. 
30 


NOT RELIED UPON TO TEACH 
THIS LIMITATION 


portal 


NOT RELIED UPON TO TEACH 
THIS LIMITATION 


Abstract; Pg 1, Para. 2-Pg 2, Para. 
18 ; See Also Third Office Action, 
Pages 3-4 


a composite profile 
generator configured to 
combine a plurality of 
MSWP profiles into a 
single, composite profile 

for routing payment 
messages in said proxy to 
the MSWP; 


Pg2, Pars. 21,30 


NOT RELIED UPON TO TEACH 
THIS LIMITATION 



Application/Control Number: 10/758,853 
Art Unit: 3692 



Page 16 



portal 


NOT RELIED UPON TO TEACH 
THIS LIMITATION 


Abstract; Pg 1, Para. 2-Pg 2, Para. 
18 ; See Also Third Office Action, 
Pages 3-4 


and, selection logic 
configured to process a 
user selection of one of 
said MSWP's to process a 
payment transaction 
received through said 
proxy 


Figs. 3-4,7; Pg 2, Pars. 21-30 


NOT RELIED UPON TO TEACH 
THIS LIMITATION 



3. The Third Office Action 

As alluded to above, the Examiner is now asserting that Suzuki teaches all of the 
claimed limitations with the exception of "wallet portal." This assertion, by the Examiner, 
raises several issues. The first issue is that the term "wallet portal" is not found 
anywhere within the claims. As such, Appellant is not entirely clear as to what limitation 
the Examiner is alleging not taught by Suzuki and what limitation the Examiner is relying 
upon Schuba to teach. The other issues revolve upon the issues initially raised by 
Appellant in the First Response. As discussed in the First Appeal Brief, the Examiner's 
response in the Second Office Action only addressed one of these arguments. In the 
Third Office Action, the Examiner has again failed to address these previously 
presented arguments. 

Returning to the first issue, the only portal found within claim 1 is the subject of 
claim 1 itself (i.e., "[a] mobile server wallet provider (MSWP) portal comprising ..."). 
Thus, assuming that the Examiner intended to assert that Suzuki does not identically 
disclose the MSWP portal," the Examiner's assertion is analogous to having a claim 
directed to "a bicycle, comprising two wheels, a seat ...) with the Examiner asserting 
that the primary reference does not teach a bicycle. As such, the Examiner has not 
clearly indicated that alleged scope and content of the applied prior art. Turning to the 
newly presented secondary reference of Schuba, the Examiner asserted the following in 
the paragraph spanning pages 3 and 4 of the Third Office Action: Schuba, in a similar 
environment, teaches a wallet portal where a mobile server wallet transaction takes 
place. The Examiner notes that Schuba discusses the usage of a wallet server, which 
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comprises an entity that operates between a merchant and a customer. This 'single 
entity' is located within the transaction between the merchant and a consumer and is 
used by both. The consumer communicates with the wallet, and the wallet, in turn, 
communicates with the merchant through the merchant's website. In effect, it would be 
obvious to conclude that this entity is thus likened to serve as a "portal' in order to 
achieve successful system interoperability as disclosed; henceforth, a portal is taught in 
Schuba. Additionally, there are number of servers within the system of Schuba 
(//Unarguably, the server which corresponds more effectively to the operation of 
a proxy, teaches the proxy server of the instant application//). Furthermore, it is old and 
well known in the art that upon use of a mobile wallet, a composite profile is created for 
a user/subscriber in order to allow for quicker usability during each 
successive/subsequent use, thereby reducing the continuous data/bandwidth input into 
the system caused via each transaction. Notable in its absence is the failure, by the 
Examiner, to specifically point to any of the teachings in Schuba. The Examiner has 
neither referred to paragraph number, page and line number, reference number, nor 
figure. Turning to the Examiner's specific allegation, the Examiner is asserting that 
Schuba discloses a wallet server that operates between a merchant and customer and 
concludes, on this basis, that Schuba discloses a "portal." However, referring to Fig. 3, 
Suzuki also discloses a wallet server that operates between a merchant (i.e., shop 
server) and a customer (i.e., user terminal). As such, if the Examiner is relying upon 
Schuba to teach a "portal," Appellant is unclear as to why Suzuki was not relied upon to 
teach the "portal." As such, the Examiner appears to be using inconsistent logic when 
asserting that Suzuki does not teach a portal whereas Schuba does. 

The Examiner's analysis regarding the alleged benefit for making the proposed 
modification is found in the first full paragraph on page 4 of the Third Office Action and 
reproduced below: At the time of the invention it would have been obvious to one of 
ordinary skill in the art to modify the teachings of Suzuki for a relay server, relaying 
method and payment system with the features of Schuba for an electronic wallet server 
payment transaction for the purpose of creating a greater more robust and efficient 
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system that also allows for ease of user interaction and protection/safety for user when 
making payments and/or transactions while using the system (Schuba: Page 1, 
Paragraph 0002-Page 2, Paragraph 0018). 

Notwithstanding that the Examiner is alleging to modify Suzuki to include 
limitations that is already disclosed by Suzuki (based upon the logic the Examiner 
employed to assert that Schuba teaches the limitations), one having ordinary skill in the 
art would recognize that these benefits would already be obtained by the practice of 
Suzuki alone. In conclusion with regard to claim 1, despite the Examiner reopening 
prosecution to include the secondary reference of Schuba within the rejection, the 
Examiner has not pointed to any teachings that are different than the teachings the 
Examiner already relied upon when previously rejecting claim 1 under 35 U.S.C. § 102 
for anticipation based upon Suzuki. Moreover, the Examiner has not addressed the 
arguments previously presented by Appellant, which still apply to the present rejection 
and have been outstanding since Appellant's response to the First Office Action. 

3. The Examiner does not find this argument to be persuasive and 
discusses the argument in detail below: 

The Examiner notes that the Schuba reference has been relied upon to disclose 
a MSW "portal" not a "wallet portal" as mentioned by Appellants supra. It should be 
noted that the Schuba reference specifically teaches a MSW "portal" whereas the 
Suzuki reference shows a "wallet portal" or "portal", as it were, in relation to the 
discussion cited from the Examiner supra. Thus, one having ordinary skill in the art 
would recognize that such benefits would not already be obtained by the practice of 
Suzuki alone. 
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4. Claims 3 and 6 

On pages 9 and 10 of the First Response, Appellant presented the following 
arguments. Each of claims 3 and 6 are directed to the concept of a filter plug-in 
configured to route payment messages to the portal when the payment messages 
match rules specified within the composite profile. With regard to these limitations, the 
Examiner cited paragraphs [0028]-[0029] and [0033]-[0038] of Suzuki and stated "[a]fter 
authentication takes place within the network, payment receipt messages are routed 
back and forth through the system." Completely absent from these passages, however, 
is a teaching as to a filter plug-in or "rules specified within the composite profile." Thus, 
the Examiner has failed to establish that Suzuki identically discloses the claimed 
invention, as recited in claims 3 and 6, within the meaning of 35 U.S.C. § 102. 

Examiner's Response 

The Examiner's sole response to the above-reproduced arguments is found in 
the paragraph spanning pages 9 and 10 of the Second Office Action in which the 
Examiner asserted the following: The Examiner respectfully disagrees. It is commonly 
known to a person of ordinary skill in the art that a filter is involved in an initiation of an 
electronic payment transaction, a communication terminal of a customer, or a 
transaction server. A filter serves as a primary part of the communication system; the 
communication system allows a communication between the server of the merchant, 
the communication terminal and the transaction server. The filter, has, among others, 
the task of forwarding certain messages concerning the electronic payment transaction 
to assigned receivers. Filters can be a part of a communication system, such as a GSM, 
GPRS, PPDC, WCDMA, UMTS, Bluetooth type networks, etc. by way of example. In 
addition, the filter allows among others, that certain messages be redirected to the 
transaction server for the communication terminal. 

Appellant is unclear as to whether or not the Examiner is making an obviousness 
rejection or yet another factually unsupported inherency argument. In either instance, 
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the Examiner has failed to set forth any substantial evidence needed for establishing 
either obviousness or inherency. 

Third Office Action 

On page 5 of the Third Office Action, the Examiner presented the following 
additional assertions: The Examiner takes Official Notice to the fact that it is quite 
common and well known to one of ordinary skill in the art that a filter be involved in an 
initiation of an electronic payment transaction, a communication terminal of a customer, 
or a transaction server. A filter serves as a primary part of the communication system; 
the communication system allows a communication between the server of the 
merchant, the communication terminal and the transaction server. The filter has, among 
others, the task of forwarding certain messages concerning the electronic payment 
transaction to assigned receivers. Filters can be a part of a communication system, 
such as a GSM, GPRS, PPDC, WCDMA, UMTS, and Bluetooth type networks by way 
of example. In addition, a filter allows for, among other things, the ability for certain 
messages to be redirected to the transaction server for the communication terminal. 

Despite the Examiner's taking Official Notice, the Examiner has not only failed to 
produce any substantial evidence to support the Examiner's allegations, even assuming 
arguendo that the Examiner is, in fact, correct, the Examiner has not even alleged that 
that the prior art teaches all of the claimed limitations. The limitation at issue is "said 
WSP further comprises a filter plug-in configured to route said payment messages to 
the portal when said payment messages match rules specified within said composite 
profile." The Examiner, however, has only argued that a filter can be used in an 
electronic payment transaction. Assuming arguendo that this is true, such an allegation 
does not lead to the legal conclusion that all of the limitations recited in claim 3 would 
have been obvious to one having ordinary skill in the art. Instead, all the Examiner 
would have established that a filter is used but not how the filter is used and where the 
filter is disposed. 
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4. The Examiner does not find this argument to be persuasive and 
discusses the argument in detail below: 

The Examiner notes that Suzuki discloses a relay server, relaying method and 
payment system. Support for any discussion of a filter within the Third Office Action can 
be found at least in the Schuba reference at Paragraphs 0002, 0027-0031 , and in Claim 
7. Furthermore, the legal conclusion that all of the limitations recited in claims 3 and 6 
would have been obvious to one having ordinary skill in the art because such a system 
and method could not operate without some form/type of constraints, or 'rules' as it 
were. 

(11) Related Proceeding(s) Appendix 

Although an Appeal has been filed in related U.S. Patent Application No. 
10/675,503, no decision rendered by a court or the Board is identified by the Examiner 
in the Related Appeals and Interferences section of this examiner's answer regarding 
such matter. 

For the above reasons, it is believed that the rejections should be sustained. 

espectfully submitted, 

/BENJAMIN S. FIELDS/ 
Patent Examiner, Art Unit 3692 
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Vincent Millin A/IW 
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Supervisory Patent Examiner, Art Unit 3692 



